Anthony Chu

When building HTTP APIs, it can be tempting to synchronously run long-running tasks in a request handler. This approach can lead to slow responses, timeouts, and resource exhaustion. If a request times out or a connection is dropped, the client won't know if the operation completed or not. For CPU-bound tasks, this approach can also bog down the server, making it unresponsive to other requests.

In this post, we'll look at how to build an asynchronous HTTP API with Azure Container Apps. We'll create a simple API that implements the Asynchronous Request-Reply pattern: with the API hosted in a container app and the asynchronous processing done in a job. This approach provides a much more robust and scalable solution for long-running tasks.

In my last post on how to deploy a serverless Playwright app to Azure Container Apps, I promised that I'd write a follow-up article "soon" on how to run Playwright in Azure Container Apps using a scheduled job. Well, it's been almost nine months, but here we are!

Azure Container Apps jobs

There are two types of resources in Azure Container Apps: apps and jobs. Apps are long-running services that respond to HTTP requests or events. Jobs are tasks that run to completion and can be triggered by a schedule or an event.

It's easy to build a job. It can be any process that you can put into a container image. Today, we'll use Node.js to create a Playwright job that runs every five minutes. Each time it runs, it'll do the following:

1. Open a browser
2. Navigate to Playwright's home page
3. Navigate to a few other pages
4. Output the these metrics to Application Insights:
   • The time it took to navigate to each page
   • The Playwright website's availability, as determined by whether all the pages loaded successfully
5. Save a video recording of the browser session to Azure Storage

In the three years since I wrote about running headless browsers with Playwright and Puppeteer in Azure Functions, I've regularly received questions about it. While it's clear that there's a lot of interest in this topic, it's also clear that it's not the easiest thing to do. Running Playwright or Puppeteer in Azure Functions requires very specific dependencies and deployment steps that are difficult to get right.

I still love Azure Functions, but I now work on Azure Container Apps, a service that makes it easy to run containerized apps and microservices. In many ways, the two services are quite similar — they're both serverless with a consumption-based pricing model; and they both support HTTP and event-driven workloads. But while Azure Functions offers a super productive programming model, Container Apps offers the flexibility and control that comes from running in containers.

Because we need a highly customized compute environment to run Playwright (or Puppeteer), it's a great fit for containers and Azure Container Apps. Some of the benefits of running Playwright in Azure Container Apps include:

• Get full control over the container image. Playwright ships a pre-built image that we can use that already has all required dependencies installed. We can add our app and anything else we need to run it.
• Run Chromium, Firefox, and WebKit. Playwright's image supports and comes with all three browsers.
• Pay only for what we use. Azure Container Apps is a serverless platform that scales our app to zero when there are no requests. We only pay for the time our app is running.
• Eliminate cold starts. Azure Container Apps offers an optional idle billing mode that keeps our app running at all times so there are no cold starts. We're charged a much lower rate when the app is idle and isn't processing requests.

In this article, we'll look at how to run Playwright in Azure Container Apps in a web API scenario. We'll use Playwright to take a screenshot of a web page and return it as a response. In a follow up article, we'll look at how to run Playwright in Azure Container Apps using a scheduled job.

Azure Static Web Apps includes built-in authentication with identity providers such as Azure Active Directory and GitHub. There's no configuration required to allow users to log in to a static web app.

The built-in Azure Active Directory authentication allows accounts from any Azure AD or personal Microsoft Accounts to log in. To restrict login to users in a specific Azure AD tenant or to specific users in an Azure AD tenant, we can configure Azure Static Web Apps custom authentication.

A couple of weeks ago, we looked at how to use Puppeteer with Node.js Azure Functions to take screenshots of web pages. Today, we'll look at how to render PDFs in Azure Functions using Razor and the C# port of Puppeteer, PuppeteerSharp.

Update 2023-08-31: If you're having trouble running Playwright or Puppeteer on Azure Functions, check out Serverless Playwright the easy way with Azure Container Apps.

A common usage of this is generating something like an invoice. We'll create PDF invoices for our favorite fictitious online store, Tailwind Traders.

Overview

We'll run ASP.NET Core Razor Pages in a .NET Azure Functions app and use PuppeteerSharp with headless Chromium to render the invoice Razor template to a PDF.

In the rest of this article, we'll walk though these steps:

1. Build an ASP.NET Core Razor Pages app that includes a Razor template and other resources required to render the invoice.
2. Create an Azure Functions app and configure it to run PuppeteerSharp.
3. Run the ASP.NET Core Razor Pages app in the function app.
4. Write a function that uses PuppeteerSharp to render the invoice and generate a PDF.
5. Deploy the app to Azure.